home *** CD-ROM | disk | FTP | other *** search
/ Developer CD Series 1996 April: Mac OS SDK / Dev.CD Apr 96 SDK / Dev.CD Apr 96 SDK1.toast / Development Kits (Disc 1) / OpenDoc / Documentation / Tech Notes & Articles / Recipes / Standards / Document Exchange < prev    next >
Encoding:
Text File  |  1995-04-21  |  2.1 KB  |  55 lines  |  [TEXT/ttxt]
  1. OpenDoc™ Recipes
  2.  
  3. Document Exchange
  4. By The OpenDoc Design Team
  5. April 20th, 1995
  6.  
  7. © 1993-1995  Apple Computer, Inc. All Rights Reserved.
  8. Apple, the Apple logo, and Macintosh are registered trademarks of Apple Computer, Inc.
  9. Mac and OpenDoc are trademarks of Apple Computer, Inc.
  10.  
  11. Document Exchange
  12.  
  13. OpenDoc is intended to be a cross-platform architecture. Document Exchange is a general term referring to the ability for any platform to manipulate documents that are created on the same or other platform.
  14.  
  15.  
  16. OpenDoc meta-data (persistent)
  17.  
  18. Data format:
  19.  
  20. Date:    Seconds since 1/1/70 (GMT)
  21. Floating Point:    IEEE + size
  22. Integer:    1,2,4 bytes (signed and unsigned)
  23. Boolean:    1-Byte, 0 = FALSE
  24. Fixed Point:    16.16
  25. ISOString (non user-visible):    Null-terminated 7-bit ASCII    
  26. View Type:    ISOString
  27. Presentation:    ISOString
  28. User-visible string:    kODIntlTxt (ISO 10646,1993UCS standard)
  29. Transform:    3x3 Fixed, 16.16
  30. Shape:    Polygon
  31. Persistent Reference:    Array of 4 bytes (NOT long)
  32. Icon:    ODIconData
  33.  
  34. Endianess:
  35.  
  36. All OpenDoc meta-data is stored in little endian.
  37.  
  38. Alignment:
  39.  
  40. Natural Alignment (i.e., 8-bit Boundaries for bytes, 16-bit boundaries for 16-bit types and 32-bit boundaries for 32 bit types.)
  41.  
  42. Coordinate system:
  43.  
  44. ODPoint uses 16.16  Fixed and the default top-level coordinate system for an OpenDoc Document is one unit equals 1/72 of an inch.
  45.  
  46.  
  47. Implications to Parts:
  48.  
  49. OpenDoc meta-data and parts:
  50.  
  51. In general, parts do not have to worry about the OpenDoc meta-data. The API hides most of the cross-platform details from the parts. For example, An ODShape associated with an ODFrame is stored persistently in little-endian format. When the frame internalizes the shape, it will do the necessary conversion so that the runtime ODShape object uses the endianess favored by the platform. Only when a part needs to access the OpenDoc meta-data stored in persistent storage directly does it have to worry about the persistent document exchange format.
  52.  
  53. Cross-platform parts:
  54.  
  55. Parts have complete control over their data format. Therefore, they don’t have to follow the same standard as OpenDoc meta-data. However, one should try to make one’s part as inspectable on persistent storage as possible.